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(57) ABSTRACT 

In a client/server system, a method and apparatus for hand- 
ing requests for access to a host resource purportedly on 
behalf of a client from an untrusted application server that 
may be capable of operating as a "rogue" server. Upon 
receiving a service request from a client, an untrusted 
application server creates a new thread within its address 
space for the client and obtains from the security server a 
client security context, which is anchored to the task control 
block (TCB) for that thread. The client security context 
specifies the client and indicates whether the client is an 
authenticated client or an unauthenticated client. When the 
application server makes a request for access to a host 
resource purportedly on behalf of the client, the security 
server examines the security context created for the request- 
ing thread. If the client security context indicates that the 
client is an authenticated client, the security server grants 
access to the host resource if the client specified in the client 
security context is authorized to make the requested access 
to the host resource. If the client security context indicates 
that the client is an authenticated client, the security server 
grants access to the host resource only if both the client 
specified in the client security context and the application 
server are authorized to make the requested access to the 
host resource. 

12 Claims, 4 Drawing Sheets 
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METHOD AND APPARATUS FOR of the client has "asked for" access to some resource, the 

CONTROLLING SERVER ACCESS TO A host system will require that both the client and the server be 

RESOURCE IN A CLIENT/SERVER SYSTEM authorized to the resource. Thus, the server cannot access 

any resources outside of its own scope of access authority. 

BACKGROUND OF THE INVENTION 5 More particularly, the present invention contemplates a 

method and apparatus for handing requests for access to a 

1. Field of the Invention resource purportedly on behalf of a client from an untrusted 
This invention relates to access control in a distributed application server in a client/server system, that may be 

system and, more particularly, to a method and apparatus for capable of operating as a "rogue" server. Upon receiving a 

controlling server access to a resource in a client/server 10 service request from a client, an untrusted application server 

system. creates a new thread within its address space for the client 

2. Description of the Related Art and obtains from the security server a client security context, 

4 „, . 4 , c c , . which is anchored to the task control block (TCB) for that 

Client/server systems are well known u, the field of data ^ ^ ^ 4 m and 

processing. In a client/server system, a client process > t aQ aumenticated cUent or m 

issues a request to a "served process to perform a service for " ...... . 

. . n . . . ,. . unauthenticated client, 

it. In response, the server transmits a reply to the client, „,..,.. , * 

notifying it of the results of the service. Often, the client Whe q the applicati o n server makes a re quest for access o 

process executes on a personal workstation, while the server a resourg_Durpori^yon behall fll the client, me security 

process executes on a central "host" processor; however, this serverxxarnuiesthe security context created for the request- 

is not required and the two processes can run on the same 20 mgjhffiai If the client security context indicates thatlhe 

machine. The service may be accessing or printing a file, ch6nt 15 an authenticated client the security server grants 

executing an application, or some more specialized service access to the rcsource _ rf . °* chcnt , m the client 

such as providing access control as described below. context » authorized to make the requested access 

„,„,...,« „ , . - , . to the resource. If the client security context indicates that 

The terms "client and "server" are relative to the service ^ cUem ^ aQ unauthenticated clienl> & e xrvet 

in question. Thus, the same process may be performing a tQ ^ resource Qnl if both me ^ ^ 

service for a first process while requesting a service (such as ? ^ cliem context and the application server are 

access to a resource) from a second. The intermediary authorized t0 make the requested access to ^ reS o U rce. 

process functions as a server relative to the first process and access ^ 

as a cbent relative to the second. - 4 r , . „ , r . 4 , ' 

30 of a client can be limited to only resources that the server 

Server processes of this latter type that request access to itself ^ has autnority to , other resources within the 

resources on behalf of clients present special security prob- host system m QQi access ibl e by such a client user (while 

lems. For the purpose of gauging their security exposures, the user is a client user), even though the user may have 

servers may be categorized into two general types: trusted acccss authority t0 othcr rcS ources when not executing as a 

servers and untrusted servers. Servers are considered to be 3S clicnl nc xrJCts m ^ longcr required {0 ^ authorized or 

"trusted" (or "authorized") if they originate from the entity code Reeled. H ost systems incorporating the present 

making the determination (usually the vendor of the oper- invention thus become much more attractive platforms for 

ating system) or have otherwise been carefully examined so the deve iopment of server applications, 
as to provide a high degree of assurance that they are free 

from malicious code. Servers that cannot be vouched for in ^ BRIEF DESCRIPTION OF THE DRAWINGS 

sense are regarded as "untrusted" (or "unauthorized") serv- FIG. 1 is a schematic block diagram of a client/server 

ers. system incorporating the present invention. 

Providing security contexts, which are authenticated FIG. 2 shows the steps performed by an application server 

identities, for client users in client/server applications where of the system of FIG. 1 to create a security context for a 

the server executes on a host system causes the client to have 4S client and to access a resource on behalf of a client, 

a host identity whose "scope of access authority** includes FIG. 3 shows the steps performed by the operating system 

resources within the entire host system. If not controlled, kernel of the system of FIG. 1. 

this compromises the security and integrity of the entire host FIG. 4 shows the steps performed by the host security 

system. In the prior art, the only way to control the scope of server of the system of FIG. 1 to create a client security 

authority of clients was to make the server code "autho- 50 context. 

rized" and carefully inspect any such code to make sure that pi G 5 shows the steps performed by the host security 

it didn't misbehave. server of the system of FIG. 1 to process a request for access 



SUMMARY OF THE INVENTION 



to a resource. 

FIG. 6 shows the makeup of an application service 

In accordance with the present invention, unauthorized 55 address space, 

servers will be able to issue new security service requests to piG. 7 shows the anchoring of accessor environment 

have security contexts created for their clients— they could elements (ACEEs) to the address space extension block and 

do this before only if they were authorized. With the new ^ control blocks of an address space, 

service, the security contexts created will be flagged as DDcccDDcn 

unauthenticated client security contexts. This is because the 60 p^nnrlfc^ 

host system cannot assume that the "unauthorized" code had EMBODIMENTS 

not manipulated the request (via troj an- horse code for Referring to FIG. 1, an exemplary client/server system 

example) to acquire the authenticated identity of someone 100 incorporating the present invention includes one or 

other than the true client or to use a valid client's identity to more clients 102 and one or more application servers 104 

do something nasty. Later, when any authorization checking 65 responsive to requests from the clients. Clients 102 and 

request comes to the host system from any resource manager servers 104 intercommunicate via a communications path 

on the host system because the server acting at the request 106. 
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Referring to FIG. 3, upon receiving this service request server 114 examines the client ACEE 708 to determine the 

from the application server 104, the OS kernel 112 checks host userid of the client 102 as well as to determine whether 

the authority of the application server 104 to use the kernel the client is a host-authenticated client or an uoauthenticated 

service to customize the security content of the thread 602 client. 

(step 302). 5 For either type of ACEE 708, the security server 114 first 

The OS kernel 112 then checks the authority of the the host security database 116 to determine whether 

application server to act as a surrogate of the host userid the client 102 specified m the client ACEE 708 is authorized 

a: ♦ t^/~o i* ♦ * *I 1A/I x to make the specified access to the resource 110 (step 504). 

corresponding to the DCE client (step 304). Jf ^ ^ ^ m ^ ^ tQ ^ 

The OS kernel 112 then invokes the services of the 110 and tennmates the aumorization checking process (step 

security server 114 to build a task-level ACEE 708 for the 10 506). 

host userid of the client 102 (step 306). if lne c ii ent 102 specified in the ACEE 708 is authorized 

Trusted application servers 104 may act as a surrogate for to make the specified access to the resource 110 (step 504), 

the client 102, meaning that only the client's host identity then the security server 114 determines whether the client 

and authorizations are used in resource access decisions 15 ACEE 708 is for a client that has been authenticated to the 

processed by the security server 114. host system 108 (step 508). If so, then the security server 114 

In contrast, untrusted application servers 104 may not act S rants access t0 me resource 110 and terminates the autho- 

as a surrogate of the client 102, and two identities are used 0231100 checking process (step 510). 

in local access control decisions on the host system 108: (1) If lhe ACEE 708 & tnat of an ^authenticated client (i.e., 

the identity of the client 102 and (2) the identity of the server 20 not authenticated to the host system 108) then the security 

104. As described below, security server 114 enforces the »rver 114 also examines the server ACEE 706 and checks 

requirement that both the host userid associated with the host security database 116 to determine whether the 

client 102 and the host userid associated with the server 104 application server 102 specified in the server ACEE 706 is 

be authorized to the resource 110 being checked. authorized to make the specified access to the resource 110 

Referring to FIG. 4, upon being invoked by the OS kernel 25 512 > If ^ * en *f ^er 114 grants access 

112 the security server 114 accesses the security database to the rGSO ™* m ™« terminates the authorization check- 

116 to obtain the host userid corresponding to the client ^ P™™ (fP Otherw^e, the security server 114 

UUID (step 402) and creates an ACEE 708 for the client's demes ac ? es ^ Xo *» resour <* U ° *? d terminates me auth °- 

host userid, which it passes back to the OS kernel 112 (step decking process (step 506). 

404) 30 Referring again to FIG. 2, when the application server 104 

rjT. , r i - . ^rr »no * j * * ai\a j j has completed processing the request from the client 102, it 

The type of client ACEE 708 created in step 404 depends ... .f 4A ™^?n 0 J\ • * > u 1* ♦ *u a 

t Jt ^ t . . - . A ^ « *l deletes the client ACEE 708 and terminates the client thread 

on the authentication status of the client as well as the £M , _ ... „, W „, M W \ 

. - . ... . 602 (or reassigns it to another client) (step 212). 

trustedness of the application server 104. ' ^ r ? , . . '\. \ 4 ' 4 . 

The foregoing description assumed that the application 

An "authenticated client" ACEE 708 is created when the sefver 1Q4 was ^ « unautnorizecr ^1 l{ me application 

client 102 has supplied host authentication credentials to the 104]ssn authorized ^ryer, then only the client ACEE 

application server 104. The application server 104 specifies 7Q8 fa checked during the authoriza tion checking procedure 

the client's host authentication credentials in its request to shown m FIG 5 ^ be acc0 mplished in any one of 

the„QS_kernel 112. By providing its host authentication manners? such by as creating ^ "authenticated 

credentials to the apphcat i on_se i yer, the cheat 102 has client" ACEE 708 for any client thread 602 of an authorized 

indicaied that it tnists^„seryer_jo_^ on its behalf. server, regaro^ess of whemer the client is aumenticated to the 

Therefore, only the accejs^nghts of the client 102 are host m Qr tQ a t s tem 

checjreduiany later access control requests^from the apph- What is claimed is: 

cation^rve7"104 on behalf of that chent, as explained 1. i n a client/server system in which a server executing on 

De l° w * 45 a host system performs application services for a client that 

On the other hand, an "unauthenticated client" ACEE 708 involve accessing a host resource, said client and said server 

is created when the client 102 is a "guest" user (such as a eacn having independently specified access rights to said 

DCE principal) that is authenticated to the guest authenti- host resource, a method of controlling server access to said 

cation system, but not to the host security server 114. In view host resource comprising the steps of: 

of the limited trust afforded by the host system 108 in this 5Q upon receiving a request from a cljent for a service from 

situation, the access rights of both the chent 102 and the a ^ creating a c Uent security context for said 

application server 104 are checked in any later access said client indi c a tin g whether 

control requests from the application server on behalf of that ^ client ^ an authenticated client that is authenti- 

client, as explained below. iQ ^ hosl system or an unauthenticated client 

Upon receiving the ACEE 708 from the security server 55 mat ^ not authenticated to said host system; 

114, the OS kernel 112 anchors the client ACEE 708 off the upon reC eiving a request for a specified access to a host 

task control block (TCB) 704 for the newly created thread resource from a server purporting to act on behalf of a 

602 before rewriting control to that thread 602 (step 308). client: 

Referring back to FIG. 2, when the application server determining whether said chent is allowed said access 

thread 602 needs to access a resource 110 (step 210), it go to said resource; 

issues a request to the OS kernel 112, which passes the determining whether said client is an authenticated 

request on to the host security server 114. client or an unauthenticated client; 

Referring to FIG. 5, upon receiving the resource access if said ciient is an authenticated client, granting said 

request from the application server 104 (via the OS kernel), access to said host resource if said client is allowed 

the host security server 114 first examines the client ACEE 65 said access to said host resource; and 

708 of the thread 602 within the server address space 600 if said client is an unauthenticated chent, determining 

from which the request originated (step 502). The security whether said server is allowed said access to said 
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resource independently of said client and granting 
said access to said host resource if both said client 
and said server are independently allowed said 
access to said host resource, otherwise, refusing said 
access to said host resource. 

2. The method of claim 1, further comprising the step of: 
storing access control information defining said access 

rights of said client and said server to said host 
resource. 

3. The method of claim 1 in which the client security 
context created for the client is examined to determine 
whether the client is an authenticated client or an unauthen- 
ticated client. 

4. In a client/server system in which a server executing on 
a host system performs application services for a client that 
involve accessing a host resource, said client and said server 
each having independently specified access rights to said 
host resource, a method of controlling server access to said 
host resource comprising the steps of: 

determining whether said client is allowed to make a 
requested access to said host resource; 

determining whether said client is an authenticated client 
that is authenticated to said host system or an unau- 
thentic at ed client that is not authenticated to said host 
system; 

if said client is an authenticated client, granting said 
requested access to said host resource if said client is 
allowed to make said requested access to said host 
resource; and 
if said client is an un authenticated client: 
determining whether said server is allowed to make 
said requested access to said host resource indepen- 
dently of said client; and 
granting said requested access to said host resource 
only if both said client and said server are indepen- 
dently allowed to make said requested access to said 
host resource. 

5. In a client/server system in which a server executing on 
a host system performs application services tor a client that 
involve accessing a host resource, said client and said server 
each having independently specified access rights to said 
host resource, apparatus for controlling server access to said 
host resource comprising: 

means responsive to the receipt of a request from a client 
for a service from a server for creating a client security 
context for said client, said client security context 
indicating whether said client is an authenticated client 
that is authenticated to said host system or an unau- 
thenticated client that is not authenticated to said host 
system; 

means responsive to the receipt of a request for a specified 
access to a host resource from a server purporting to act 
on behalf of a client for: 

determining whether said client is allowed said access 
to said resource; 

determining whether said client is an authenticated 
client or an unauthenticated client; 

if said client is an authenticated client, granting said 
access to said host resource if said client is allowed 
said access to said host resource; and 

if said client is an unauthenticated client, determining 
whether said server is allowed said access to said 
resource independently of said client and granting 
said access to said host resource if both said client 
and said server are independently allowed said 
access to said host resource, otherwise, refusing said 
access to said host resource. 



10 
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6. The apparatus of claim 5, further comprising: 
means for storing access control information defining said 

access rights of said client and said server to said host 
resource. 

7. The apparatus of claim 5 in which the client security 
context created for the client is examined to determine 
whether the client is an authenticated client or an unauthen- 
ticated client. 

8. In a client/server system in which a server executing on 
a host system performs application services for a client that 
involve accessing a host resource, said client and said server 
each having independently specified access rights to said 
host resource, apparatus for controlling server access to said 
host resource comprising: 

means for determining whether said client is allowed to 

make a requested access to said host resource; 
means for determining whether said server is allowed to 
make said requested access to said host resource inde- 
pendently of said client; 
means for determining whether said client is an authen- 
ticated client that is authenticated to said host system or 
an unauthenticated client that is not authenticated to 
said host system; 
25 means for granting said requested access to said host 
resource if said client is allowed to make said requested 
access to said host resource if said client is an authen- 
ticated client, and 
means for granting said requested access to said host 
30 resource only if both said client and said server are 
independently allowed to make said requested access to 
said host resource if said client is an unauthenticated 
client. 

9. A program storage device readable by a machine, 
35 tangibly embodying a program of instructions executable by 

the machine to perform method steps for controlling server 
access to a host resource in a client/server system in which 
a server executing on a host system performs application 
services for a client that involve accessing a host resource, 
40 said client and said server each having independently speci- 
fied access rights to said host resource, said method steps 
comprising: 

upon receiving a request from a client for a service from 
a server, creating a client security context for said 
client, said client security context indicating whether 
said client is an authenticated client that is authenti- 
cated to said host system or an unauthenticated client 
that is not authenticated to said host system; 
upon receiving a request for a specified access to a host 
resource from a server purporting to act on behalf of a 
client: 

determining whether said client is allowed said access 

to said resource; 
determining whether said client is an authenticated 

client or an unauthenticated client; 
if said client is an authenticated client, granting said 
access to said host resource if said client is allowed 
said access to said host resource; and 
if said client is an unauthenticated client, determining 
whether said server is allowed said access to said 
resource independently of said client and granting 
said access to said host resource if both said client 
and said server are independently allowed said 
access to said host resource, otherwise, refusing said 
access to said host resource. 

10. The program storage device of claim 9, further com- 
prising the step of: 



45 
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storing access control information defining said access 
rights of said client and said server to said host 
resource. 

11. The program storage device of claim 9 in which the 
client security context created for the client is examined to 5 
determine whether the client is an authenticated client or an 
unauthenticated client. 

12. A program storage device readable by a machine, 
tangibly embodying a program of instructions executable by 
the machine to perform method steps for controlling server 10 
access to a host resource in a client/server system in which 

a server executing on a host system performs application 
services for a client that involve accessing a host resource, 
said client and said server each having specified access 
rights to said host resource, said method steps comprising: 15 
determining whether said client is allowed to make a 
requested access to said host resource; 
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determining whether said client is an authenticated client 
that is authenticated to said host system or an unau- 
thenticated client that is not authenticated to said host 
system; 

if said client is an authenticated client granting said 
requested access to said host resource if said client is 
allowed to make said requested access to said host 
resource; and 
if said client is an unauthenticated client: 
determining whether said server is allowed to make 
said requested access to said host resource indepen- 
dently of said client; and 
granting said requested access to said host resource 
only if both said client and said server are indepen- 
dently allowed to make said requested access to said 
host resource. 

***** 
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Clients 102 are processes that ma either on separate aspects of the present invention may be found, however, in 

workstations (not separately shown) or on a common work- the IBM publications MVS/ESA OpenEdition DCE: RACF 

station. Application servers 104 are processes that run.on a and DCE Security Interoperation, GG24-2526-00 (1995); 

host system 108. Host system 108 also incl udes one j) r more and OS/390 Security Server (RACF) Support for: OpenE- 

resources 110 accessed by ap plication ser vers 104 on behalf 5 dition DCE, SOMobjects for MVS, SystemView for MVS, 

of their clients 102, an operating system (OS)"kerneril2, a GC28-1924-00 (1996), Both of these publications are incor- 

host security server 114 for controlling access to resources porated herein by reference. ~n 

110, a host security database 116 containing access control In a similar manner, each native (i.e., non-guest) user of I 

information used by the host security server, and a "guest" the host system 108 has a host userid (a RACE userid in the J 

security database 118 containing access control information 10 example shown) and host authentication credentials such as / 

used by "guest" application servers as described below. In a static or dynamic password. A client 102 having a host / 

the embodiment shown, it will be assumed that host system userid authenticates itself to the host security server 114 by/ 

presenting its credentials fo the server, \vnich then accesses I 



108 is an IBM System/390 (S/390) processor, OS kernel 112 presenting^ ^ | ^ . 

is the MVS OpenEdition kernel of the IBM OS/390 oper- t hrriost secu rity database 116 to verif y the credentia ls andl 

ating system, and that host security server 114 is the IBM 1S a ^nticalR .thg client. 

Resource Access Control Facility (RACF), a component of Although authentication functions in the host system 108 

OS/390. (IBM, System/390, S/390, MVS, OpenEdition, are split between the host security server 114 and guest 

OS/390 and RACF are trademarks or registered trademarks application servers 104 (or their security servers if different) 

of International Business Machines Corporation, the in the manner described above, access by authenticated users 

assignee.) The present invention is not limited to such a 20 to host resources 110 is controlled by the host security server 

configuration, however. 114 alone. To facilitate this, host security database 116 maps 

As noted above, application servers 104 are eitheMrusted gu est userid s (such as DCE UUIDs) to corresponding host 

servers (also referred to herein as "au thorized" or "host" use nds sq that similar access controrpro cedures (with the 

servers) that are assumed to be free of malicious code or exceptions noted) may be used forbotD native users and 

untruste^eTveTS-(aTso~referred to herein as "unauthorized" 25 "guest" users such as DCE principals, 

or "guest" servers)-that~are~ not-assumed to be free of "deferring to FIG. 6, application server 104 executes 

maUcious.code. Guest application servers lWaTelu'Iowed to within a server address spac e 600 that includes one or more 

run"^nTthe host system 108, but with restricted access cUenUhreads 602; server address space 600 has_one_client 

privileges as compared with host application servers. thread 602 for each client 102 currently being processed. 

Although the present invention is not limited to any par- 30 Referring to FIG. 7, server address space 600 and each of the 

ticular guest application servers 104, in the disclosed client threads 602 within the server address space has an 

embodiment it will be assumed that they are DCE servers accessor environment element (ACEE) or security context 

conforming to the protocols of the Open Software Founda- that is used for the purposes of access control, as described 

tion (OSF) Distributed Computing Environment (DCE) and below. (The terms "ACEE" and "security context" are used 

that the clients 102 are DCE clients whose requests cause the 35 synonymously in this specification.) Thus, server address 

application server to access non-DCE (i.e., host) resources. space 600 has an address space extension block (ASXB) 702 

Host security database 116 c ontains da t a defi ning the containing a pointer to a server ACEE 706, while each client 

acc ess rights of e ntities such as clients 102 a^d^eryersj04 thread 602 has a task control block (TCB) 704 containing a 

se eSnYaccessTo resources 110 . As a prerequisite~to deter- client ACEE 708. Each of ACEEs 704 and 708 contains 

mining the access rights of users seeking access to a 40 various fields identifying the user in question; these fields 

resourc e, users are authenticated, i .e., established in some include a "client" field (C) 710 indicating whether the ACEE J 

satisfactory manner (as by" a password or other credentials) *s a client ACEE and an "authenticated" field (A) 712/ 

as being the entities they purport to be. In the disclosed indicating whether the ACEE is an authenticated clientj 

system 100, users may be aumentic ate^eimcj^to-the-host ACEE. 

sea urity server I1 47iisinff a password or other credentials 45 FIG- 2 shows the procedure followed by an application 

recognized by the host security server) or to DCE or some server 104 to handle requests from clients 102. After ini- 

other guest system (using a password or other credentials tializing (step 202), the application server 104 waits for a 

recognized by the guest security server). Clients 102 that are service request from a client 102 (step 204). If the client 102 

not authenticated to the host security server 114 (even is a DCE client, the service request may be in the form of a 

though they may be authenticated to a guest system such as 50 remote procedure call (RPC) containing, among other 

DCE) are referred to herein as "unauthenticated" clients . things, the client's PAC. 

Application servers 104 may access resources on behalf of Upon receiving the service request from the client 102, 

such "unauthenticated" clients 102, but with additional the application server 104 issues a request to the guest 

restrictions as described below. security database 118 to obtain the client's credentials 

Each DCE user (or principal, to use the conventional DCE 55 (including the UUID) from the PAC transmitted as part of 

term) has what is known as a unique universal identifier the RPC (step 206). 

(UUID) that specifies the user's identity in a DCE environ- The application server 104 then creates a new thread 602 
ment. A DCE client 102 authenticates itself to a DCE within its address space 600 for the client 102 and "custom- 
application server 104 by presenting satisfactory credentials izes" the thread with the client's host identity (i.e., its host 
to the server, which then accesses the guest security database 60 userid) by issuing a service request containing the client's 
118 to verify the credentials and authenticate the DCE client. UUID to the OS kernel 112 to obtain an ACEE 708 for the 
DCE credentials take the form of a privilege attribute client (step 208). If the client 102 has presented host 
certificate (PAC) specifying among other things the UUID of authentication credentials to the application server 104, 
the client principal 102 and the groups of which the principal these also are passed along to the OS kernel 112, thence to 
is a member. The manner in which PACs are formed under 65 the host security server 114, to permit the host security 
the DCE protocol is well known in the art and forms no part server to authenticate the client and give it an "authenticated 
of the present invention. Further information on this an other client" ACEE 708. 
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